Mobile telehealth system and method

ABSTRACT

A system and methods are used to provide patients access to in-home healthcare, for example, using a device in conjunction with a mobile device. The system and methods described herein are used for tooth whitening applications, general dental or medical checkups, detecting disease, updating dental or medical records, and automatic ordering of prescription and non-prescription products.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and the benefit of U.S. ProvisionalPatent Application Ser. No. 63/192,797, filed May 25, 2021, and U.S.Provisional Patent Application Ser. No. 63/286,162, filed Dec. 6, 2021,the entire disclosures of which are hereby incorporated by reference.

TECHNICAL FIELD

This disclosure relates to systems and methods for mobile telehealth.

BACKGROUND

Independent healthcare providers typically struggle to grow theirpractices and provide greater access to their patients. One way to growtheir practice is to join an established healthcare system. Joining anestablished healthcare system has several drawbacks. For example, thehealthcare provider loses their independence and scheduling flexibility.From the patient perspective, established healthcare systems may providegreater access to a healthcare provider, however, their choices ofparticular healthcare providers may be limited, particularly in offhours. Accordingly, a system is needed for independent healthcareproviders to provide their services to a larger population of patients,provide greater access to care for patients, and maintain theirindependent practices.

SUMMARY

Disclosed herein are implementations of a mobile telehealth system. Inan aspect, a method may include obtaining a patient selection. Thepatient selection may be obtained via a user interface of a first mobiledevice. The method may include obtaining an appointment selection. Theappointment selection may be obtained via the user interface of thefirst mobile device. The method may include obtaining a medical history.The medical history may be obtained via the user interface of the firstmobile device, and electronic health records (EHR) system, or both. Themethod may include obtaining payment information. The paymentinformation may be obtained via the user interface of the first mobiledevice. The method may include transmitting an invitation to a secondmobile device in response to obtaining the payment information. Themethod may include receiving a first notification from the second mobiledevice. The method may include obtaining a check in. The check in may beobtained via the user interface of the first mobile device. The methodmay include transmitting a second notification to the second mobiledevice in response to obtaining the check in. The method may includeopening a channel between the first mobile device and the second mobiledevice. The channel may be a real-time session channel to conduct atelehealth visit.

In an aspect, a method may include automatically populating patientinformation to generate an electronic prescription. The method mayinclude obtaining prescription information. the prescription informationmay include a prescribed medication. The prescription information may beobtained via a user interface of a first device. The method may includetransmitting the electronic prescription to a pharmacy. The electronicprescription may include the patient information, the prescriptioninformation, or both. The method may include transmitting a confirmationthat indicates that the transmission of the electronic prescription tothe pharmacy is complete.

In an aspect, a method may include receiving data from a device. Themethod may include displaying the data. The method may includedetermining a tooth shade based on the data. The method may includeobtaining electronic health record (EHR) data. The method may includedetermining a product. The product may be determined based on the toothshade, the EHR data, or both.

In an aspect, a method may include receiving data from a device. Themethod may include displaying the data. The method may includedetermining tooth decay based on the data. The method may includeobtaining electronic health record (EHR) data. The method may includedetermining a product. The product may be determined based on the toothdecay, the EHR data, or both.

In an aspect, a method may include receiving data from a device. Themethod may include displaying the data. The method may includedetermining a disease state based on the data. The method may includeobtaining electronic health record (EHR) data. The method may includedetermining a product. The product may be determined based on thedisease state, the EHR data, or both.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure is best understood from the following detaileddescription when read in conjunction with the accompanying drawings. Itis emphasized that, according to common practice, the various featuresof the drawings are not to-scale. On the contrary, the dimensions of thevarious features are arbitrarily expanded or reduced for clarity.

FIG. 1 is a block diagram of an example of a mobile telehealth system.

FIG. 2 is a block diagram of an example architecture of a mobiletelehealth system.

FIG. 3 is a block diagram of an example of a mobile device.

FIG. 4 is a diagram of an example of an appointment scheduling workflow.

FIG. 5 is a flow diagram of an example of a healthcare providerqualification method.

FIG. 6 is a flow diagram of an example of a method for scheduling anappointment.

FIG. 7 is a flow diagram of an example of a method for electronicprescription.

FIG. 8 is a diagram of a universal dentition chart in accordance withembodiments of this disclosure.

FIG. 9 is a diagram of an example of the mobile telehealth system shownin FIG. 1 .

FIG. 10 is a flow diagram of an example of a method for home healthcareaccess.

DETAILED DESCRIPTION

Embodiments described herein may allow patients to connect in real-timewith a healthcare provider of their choice, for example, through videoand/or chat on a mobile device. A healthcare provider may include anymedical professional that provides medical, dental, or veterinaryservices. The system described herein may be used for new patientvirtual visits, emergency consultations, and virtual checkups forestablished patients. The system may allow for the patient andhealthcare provider to build a relationship such that the healthcareprovider has personalized knowledge of the needs of the patient and theability to stay connected.

Similar to an in-person visit, the system is configured to obtain thepatient history and symptoms, perform a virtual examination, recommendtreatment, and prescribe medications. Medical records, dental records,or both, may be uploaded to the system. The system allows for thepatient to meet with the healthcare provider in a private space withoutthe stress of a typical office visit. The system may includeaccessibility features such as magnification and/or visual aids, audioenhancement, or any combination thereof, for creating efficiency andease of use for patients and healthcare providers with disabilities suchas visual or hearing impairment. The system may be configured to performautomatic translations of medical records to that they can betransmitted and viewed on mobile devices to patients and healthcareproviders anywhere.

FIG. 1 is a block diagram of an example of a mobile telehealth system100. The mobile telehealth system 100 includes a server 110, a mobiledevice 120, a mobile device 130, and in some embodiments, an electronichealth records (EHR) system 140.

The server 110 may be a computer hardware device or software thatprovides functionality for other programs or devices known as clients.The clients may be mobile devices such as mobile device 120 and mobiledevice 130. In some examples, the EHR system 140 may be a client. Theserver 110 may provide services, such as sharing data or resources amongmultiple clients and devices. The server 110 may perform computationsfor a client.

In this example, the mobile device 120 may be a patient mobile deviceand the mobile device 130 may be a healthcare provider mobile device.The mobile device 120 may be configured to run software, such as anapplication, to communicate with the server 110. The mobile device 130may be configured to run software, such as an application, tocommunicate with the server 110. The mobile device 120 may be configuredto obtain an existing patient selection or addition of a new patient.The selection or addition of a patient may be obtained via an input onthe mobile device 120, such as a touch input or a voice input. Themobile device 120 may be configured to transmit the selection oraddition of the patient to the server 110.

The mobile device 120 may be configured to query the server 110 toobtain a list of available appointment slots in a schedule of thehealthcare provider. The mobile device 120 may be configured to obtainan appointment selection from the patient. The appointment selection maybe obtained via an input on the mobile device 120, such as a touch inputor a voice input. The appointment selection may be based on an availableappointment slot in the schedule of the healthcare provider stored onthe server 110. The mobile device 120 may be configured to transmit theappointment selection to the server 110. The server 110 may receive theappointment selection and update the schedule of the healthcare providerto indicate that the selected appointment is tentative.

The mobile device 120 may be configured to obtain a medical history ofthe patient. The medical history may be obtained via an input on themobile device 120, such as a touch input or a voice input. The mobiledevice 120 may be configured to transmit the medical history to theserver 110. In some embodiments, the mobile device 120 may be configuredto upload one or more documents and/or images to the server 110. In someembodiments, the server may obtain a medical history or a portion of amedical history from the EHR system 140. The EHR system 140 isassociated with the healthcare provider. The EHR system 140 isconfigured to store electronic health records of patients of thehealthcare provider. The EHR system 140 may be located on premises atthe office of the healthcare provider, or it may be at a remote locationaway from the healthcare provider office. In an example, the server 110may obtain an EHR from the EHR system 140. The server 110 may beconfigured to receive the medical history or portions of the medicalhistory from the mobile device 120 and the EHR system 140, compile themedical history, and transform the compiled medical history into aunified format. The unified format of the medical history may be storedon the server 110. The unified format may be an alphanumeric format, avisual format, or a combination of both. The unified format is generatedusing the received inputs to create a labeled map. For example, thedental chart, with the visual representation of teeth is annotated withthe information gathered, such as a tooth with decay, chipped tooth,etc. This information may be compiled and unified by placing theinformation into one document associated with a given patient and storedin the cloud.

The mobile device 120 is configured to obtain payment information. Insome embodiments, the payment information can include crypto tokens. Thecrypto tokens may be Ethereum Request for Comments 20 (ERC-20) orEthereum Improvement Proposals (EIP-20) tokens. The crypto tokens may bestored on the Ethereum blockchain. The application may include a cryptowallet that allows users to check their crypto token balance and performsupported transactions within the application. The crypto wallets mayuse Ethereum application programming interfaces (API)s. In an example,crypto tokens may be earned by using certain features of the system,such as watching a video, completing a quiz or tutorial, or the like. Inan example, crypto tokens may be awarded for a healthcare achievement,such as a health goal, which can be verified as accomplished within theapplication. The payment information may be transmitted to the server110. The server 110 may store the payment information. The server 110 isconfigured to process the payment and send an invitation to the mobiledevice 130. The invitation may include information associated with theappointment, for example date, time, type of appointment, patient name,patient symptoms, and any other relevant patient information. The mobiledevice 120 may be configured to display an indication of the proposedappointment on the display of the mobile device 120. The mobile device130 is configured to obtain a confirmation from the healthcare provider.The confirmation may be obtained via an input on the mobile device 130,such as a touch input or a voice input. The mobile device 130 maytransmit a notification to the server 110. The notification may indicatethat the appointment is confirmed.

The server 110 is configured to transmit the notification to the mobiledevice 120. The mobile device 120 is configured to receive thenotification and display an indication of the confirmed appointment onthe display of the mobile device 120. The mobile device 120 isconfigured to obtain a check in from the patient. The check in mayindicate that the patient is ready to start the telehealth visit. Thecheck in may be obtained via an input on the mobile device 120, such asa touch input or a voice input. The mobile device 120 may transmit anotification to the server 110 in response to the input. Thenotification may indicate that the patient is ready to start thetelehealth visit. The server 110 is configured to receive thenotification and transmit the notification to the mobile device 130.

The mobile device 130 is configured to receive the notification. In someexamples, the mobile device 130 may display the notification on adisplay, such as the display of the mobile device 130. The mobile device130 may be configured to obtain an indication to initiate the telehealthvisit. The indication may be obtained via an input on the mobile device130, such as a touch input or a voice input. In response to receivingthe indication, the mobile device 130 may transmit a command to theserver 110 to initiate the telehealth visit.

The server 110 is configured to receive the command and open a channelbetween the mobile device 120 and the mobile device 130. The channel maybe configured as a real-time session channel to conduct the telehealthvisit. The channel may be configured to support real-time audio andvideo communications.

To further illustrate an example use case for the mobile telehealthsystem 100, the following is provided. In an example, for the patient tobe ready to be checked in, they will have had to complete the necessaryfields in the medical and/or dental history, as well as have had entereda means of payment (or a code associated with a user type to bypasspayment). The mobile device 120 may receive a pop-up notificationreminding the patient to check into the virtual waiting room of theapplication. The patient, having checked into the waiting room, becomesvisible to the healthcare provider via the mobile device 130. The mobiledevice 130 receives a notification that the patient, is in the virtualwaiting room. The mobile telehealth system 100 may perform a matching ofthe patient name and appointment time. Both parties are alerted whenthey are a predetermined time (e.g., 10 minutes) from starting anappointment and are advised to be ready.

FIG. 2 is a block diagram of an example architecture of a mobiletelehealth system 200. The mobile telehealth system 200 includes atleast one mobile device 210 and a datacenter 220 that are configured tocommunicate via the internet 230. In this example, the mobile device 210may be any mobile device, such as mobile device 120 or mobile device 130shown in FIG. 1 . The mobile device 210 may be configured to runsoftware based on a model-view-viewmodel (MVVM) architecture to reducecoupling, increase maintainability, or both.

As shown in FIG. 2 , the datacenter 220 includes an elastic loadbalancer 230, an auto-scaling server group 240, a primary database 250,and a standby database 260. In an example, the server 110 shown in FIG.1 may be the auto-scaling server group 240. The auto-scaling servergroup 240 is configured to support failover and includes one or moreapplication programming interface (API) servers 270A-270C. The APIservers 270A-270C are configured to auto-scale based on rules defined toincrease the number of servers with a rise in communication traffic. TheAPI servers 270A-270C are configured to have a near constant responsetime when the number of users is increasing. In an example, the APIservers 270A-270C may be representational state transfer (REST) APIservers configured to run Java Sprint Boot with spring security OAuth2.As shown in FIG. 2 , each API server 270A-270C includes an applicationcache 280A-280C. In some examples, the application cache 280A-280C maybe configured to store data such that the data is accessible without aninternet connection.

The elastic load balancer 230 is configured to receive communicationtraffic from the at least one mobile device 210 via the internet 230.The elastic load balancer 230 is configured to route the communicationtraffic to the one or more API servers 270A-270C of the auto-scalingserver group 240. The communication traffic may be routed based on avolume of the communication traffic.

The API servers 270A-270C are configured to perform automatic backups tothe primary database 250. The automatic backups may be performed basedon a predetermined schedule. If there is a failure at the primarydatabase 250, the automatic backups may be failed over to the standbydatabase 260. The primary database 250, the standby database 260, orboth, may be PostgreSQL databases.

FIG. 3 is a diagram of an example of a mobile device 300. The mobiledevice 300 may be any mobile device, such as mobile device 120 or mobiledevice 130 shown in FIG. 1 . The mobile device 300 may be a mobilephone, a smartphone, a tablet computing device, a laptop, or any otherportable computing device. As shown in FIG. 3 , the mobile device 300includes a processor 310, a transceiver 320, an antenna 330, aspeaker/microphone 340, a display/touch interface 350, memory 360, apower source 370, a global positioning system (GPS) chipset 380, and aninertial measurement unit (IMU) 390.

The processor 310 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP),one or more microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, one or moreApplication Specific Integrated Circuits (ASICs), one or more FieldProgrammable Gate Array (FPGAs) circuits, any other type of integratedcircuit (IC), a state machine, or any other processing device. Theprocessor 310 may perform signal coding, data processing, power control,input/output processing, and/or any other functionality that enables themobile device 300 to operate in a wireless environment. The processor310 may be coupled to the transceiver 320, which may be coupled to theantenna 330. While FIG. 3 shows the processor 310 and the transceiver320 as separate components, in some embodiments, the processor 310 andthe transceiver 320 may be integrated together in an electronic packageor chip. The processor 310 may be configured to execute instructionsstored on a non-transitory computer readable medium, such as memory 360.

The transceiver 320 may be configured to modulate the signals that areto be transmitted by the antenna 330 and to demodulate the signals thatare received by the antenna 330.

The antenna 330 may be configured to transmit signals and receivesignals over an air interface. For example, the antenna 330 may beconfigured to transmit and/or receive radio frequency (RF) signals. Inan embodiment, the antenna 330 may be an emitter/detector configured totransmit and/or receive infrared (IR), ultraviolet (UV), or visiblelight signals, for example. In yet an embodiment, the antenna 330 may beconfigured to transmit and receive both RF and light signals. It will beappreciated that the antenna 330 may be configured to transmit and/orreceive any combination of wireless signals.

The processor 310 may be coupled to, and may receive user input datafrom, the speaker/microphone 340, the display/touch interface 350 (e.g.,a liquid crystal display (LCD) display unit or organic light-emittingdiode (OLED) display unit), or both. The processor 310 may also outputuser data to the speaker/microphone 340, the display/touch interface350, or both. In addition, the processor 310 may access informationfrom, and store data in, any type of suitable memory, such as the memory360. The memory 360 may include random-access memory (RAM), read-onlymemory (ROM), a hard disk, a subscriber identity module (SIM) card, amemory stick, a secure digital (SD) memory card, or any other type ofmemory storage device. In an embodiment, the processor 310 may accessinformation from, and store data in, memory that is not physicallylocated on the mobile device 300, such as on the server 110 shown inFIG. 1 or a home computer (not shown).

The processor 310 may receive power from the power source 370, and maybe configured to distribute and/or control the power to the othercomponents of the mobile device 300. The power source 370 may be anysuitable device for powering the mobile device 300. For example, thepower source 370 may include one or more dry cell batteries (e.g.,nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH),lithium-ion (Li-ion)), solar cells, fuel cells, and the like.

The processor 310 may also be coupled to the GPS chipset 380, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the mobile device 300. Inaddition to, or in lieu of, the information from the GPS chipset 380,the mobile device 300 may receive location information over the airinterface and/or determine its location based on the timing of thesignals being received from two or more nearby base stations. It will beappreciated that the mobile device 300 may acquire location informationby way of any suitable location-determination method while remainingconsistent with an embodiment.

The processor 310 may further be coupled to the IMU 390. The IMU 390 maybe configured to measure and report a specific force of the mobiledevice 300, an angular rate of the mobile device 300, an orientation ofthe mobile device 300, or any combination thereof, using one or more ofan accelerometer, a gyroscope, and a magnetometer.

FIG. 4 is a diagram of an example of an appointment scheduling workflow400. The appointment scheduling workflow 400 is shown between mobiledevice 120 and mobile device 130 shown in FIG. 1 . For simplicity andclarity, a server is not shown, however, it is understood that thecommunications between mobile device 120 and mobile device 130 areperformed through a server, such as server 110 shown in FIG. 1 .

In this example, the mobile device 120 may be a patient mobile deviceand the mobile device 130 may be a healthcare provider mobile device. Insome examples, the mobile device 120 may be configured to communicatewith one or more devices, such as devices that are configured for homemedical and/or dental use. The mobile device 120 may be configured toobtain 405 an existing patient selection or addition of a new patient,for example, from a database. The selection or addition of a patient maybe obtained via an input on the mobile device 120, such as a touch inputor a voice input. The mobile device 120 may be configured to transmitthe selection or addition of the patient to the server.

The mobile device 120 may be configured to query the server to obtain alist of available appointment slots in a schedule of the healthcareprovider. The mobile device 120 may be configured to obtain 410 anappointment selection from the patient. The appointment selection may beobtained via an input on the mobile device 120, such as a touch input ora voice input. The appointment selection may be based on an availableappointment slot in the schedule of the healthcare provider stored onthe server. The mobile device 120 may be configured to transmit theappointment selection to the server. The server may receive theappointment selection and update the schedule of the healthcare providerto indicate that the selected appointment is tentative.

The mobile device 120 may be configured to obtain 415 a medical historyof the patient. The medical history may be obtained via an input on themobile device 120, such as a touch input or a voice input. The mobiledevice 120 may be configured to transmit the medical history to theserver. In some embodiments, the mobile device 120 may be configured toupload one or more documents and/or images to the server 110. In someembodiments, the server may obtain 415 a medical history or a portion ofa medical history from an EHR system, such as the EHR system 140 shownin FIG. 1 .

The mobile device 120 is configured to obtain 420 payment information.The payment information may be transmitted to the server. The server maystore the payment information. In an example, the server is configure toprocess the payment information and transmit an invitation 425 to themobile device 130. In another example, the mobile device 120 isconfigured to transmit the invitation 425 to the mobile device 130 viathe server. The invitation 425 may include information associated withthe appointment, for example date, time, type of appointment, patientname, patient symptoms, and any other relevant patient information. Themobile device 120 may be configured to display 430 an indication of theproposed appointment on the display of the mobile device 120. The mobiledevice 130 is configured to obtain 435 a confirmation from thehealthcare provider. The confirmation may be obtained via an input onthe mobile device 130, such as a touch input or a voice input. Themobile device 130 may transmit a notification 440 to the mobile device120 via the server. The notification 440 may indicate that theappointment is confirmed.

The mobile device 120 is configured to receive the notification 440 anddisplay 445 an indication of the confirmed appointment on the display ofthe mobile device 120. The mobile device 120 is configured to obtain 450a check in from the patient. The check in may indicate that the patientis ready to start the telehealth visit. The check in may be obtained viaan input on the mobile device 120, such as a touch input or a voiceinput. The mobile device 120 may transmit a notification 455 to themobile device 130 via the server in response to the input. Thenotification 445 may indicate that the patient is ready to start thetelehealth visit.

The mobile device 130 is configured to receive the notification 455. Insome examples, the mobile device 130 may display the notification 455 ona display, such as the display of the mobile device 130. The mobiledevice 130 may be configured to obtain 460 an indication to initiate thetelehealth visit. The indication may be obtained via an input on themobile device 130, such as a touch input or a voice input. In responseto obtaining the indication, the mobile device 130 may transmit acommand to the server to initiate the telehealth visit.

The server is configured to receive the command and open 465 a channelbetween the mobile device 120 and the mobile device 130. The channel maybe configured as a real-time session channel to conduct the telehealthvisit. The channel may be configured to support real-time audio andvideo communications.

The mobile device 130 is configured to perform image and/or videocaptures of the patient using a camera of the mobile device 120. Themobile device 120 may be configured to display alignment lines to guidethe patient to properly align the mobile device 120 for the image and/orvideo capture. In some examples, the alignment lines may be displayed asdental arch overlays or facial feature overlays. In some examples,cartoon depictions of the pose may be displayed to guide the patient. Insome examples, the cartoon depictions may include a text or audibledescription of the pose. The mobile device 120 is configured to scan thepatient's face to detect whether proper alignment is achieved. Onceproper alignment is achieved, the mobile device 120 performs the imageand/or video capture. The mobile device 130 is configured to obtaininput from the healthcare provider to annotate the image and/or videocaptures in real-time. The mobile device 120 may capture a series ofimages that can be used to determine a preliminary diagnosis. Thepreliminary diagnosis may be determined based on specific orientationsor poses for images of a patient's face. For example, orienting apatient in a position such as full face, or straight profile, where thepatient's eyes, nose, and mouth are parallel to the horizon, the systemmay determine an asymmetry value. The asymmetry value may be an integervalue, and may be determined at the mobile device 120, the mobile device130, or at a server of the system, such as server 110 shown in FIG. 1 .The preliminary diagnosis may be based on a determination that theasymmetry value is above a threshold. The input may be a touch input, atext input, a voice input, or a combination thereof.

Upon completion of the telehealth visit, the mobile device 130 isconfigured to obtain 470 an indication of visit completion. Theindication of visit completion may be obtained via an input on themobile device 130. The input may include a touch input or a voice input.In response to obtaining the indication of visit completion, the mobiledevice 130 may transmit a notification 475 to the mobile device 120 viathe server. The notification 475 may indicate that the appointment iscompleted. The mobile device 120 may be configured to display 480 thenotification 475, for example, on a display of the mobile device 120.

Upon completion of, or during the telehealth visit, the mobile device130 may be configured to provide the healthcare provider the ability towrite an electronic prescription (e-prescription). The mobile device 130may be configured to add appointment notes. The appointment notes may beadded via text input, voice input, or any other suitable input. Theappointment notes entry may be enhanced with spell-checking,particularly for industry or specialty specific terminology. Theappointment notes entry may include pre-designed templates and one ormore elements that are auto-filled with data from a memory. The mobiledevice 130 may be configured to save the image and/or video captures,for example, with or without annotations. The images, video captures,and/or annotations may be saved in the appointment notes portion of anelectronic file associated with the patient. The mobile device 130 maybe configured to mark the appointment as completed. The mobile device130 may be configured to automatically send a post-visit summary to thepatient, for example, via email, short messaging service (SMS) text, orsome other method.

Upon completion of the telehealth visit, the mobile device 130 may beconfigured to access an e-prescription. The mobile device 120 may beconfigured to view the appointment notes. The mobile device 120 may beconfigured to view the image and/or video captures, for example, with orwithout annotations. An example annotation of an image may include acircle drawn around, or an arrow pointing to, an area of concern on theimage, such as a decaying or broken tooth. The mobile device 120 may beconfigured to receive the post-visit summary, for example, via email,SMS text, or some other method.

FIG. 5 is a flow diagram of an example of a healthcare providerqualification method 500. The method 500 includes obtaining 510registration information. The obtained registration information may betransmitted to a server, such as server 110 shown in FIG. 1 , forprocessing. The registration information may be obtained via anycomputing device, such as, for example, mobile device 130 shown in FIGS.1 and 4 . The registration information may include educationalexperience, such as degrees and specialty certificates earned, residencyprograms completed, or any combination thereof. The registrationinformation may include state licensing verification, practice history,experience, patient reviews, or any combination thereof. Theregistration information may include disciplinary matters, including,for example, medical malpractice claims. The registration informationmay include hospital privileges, whether granted, denied, or revoked. Inan example, the registration may include the first and last name of thephysician, email address, phone number, type of implementation, name ofpractice, location of practice, website, individual national provideridentifier (NPI), practice NPI, professional license number, state, andrenewal date, or any combination thereof. The type of implementation maybe chosen from a dropdown menu and may include a standard free downloadand a premium download that includes an e-prescribing feature.

The method 500 includes automatically verifying 520 the registrationinformation. In response to verifying the registration information, themethod 500 includes determining 530 whether the healthcare provider isqualified. The determination of the qualification of the healthcareprovider is based on the automatic verification of the registrationinformation. For example, if one or more elements of the obtainedregistration information (or some other threshold) cannot be verified,the healthcare provider may be deemed unqualified. If it is determinedthat the healthcare provider is not qualified, the method 500 includestransmitting 540 a rejection message to the computing device. Therejection message may be transmitted as an email, an SMS text, or someother communication. The determination of the qualification of thehealthcare provider may be performed using a third party softwareservice.

If it is determined that the healthcare provider is qualified, themethod 500 includes generating 550 a unique code. The unique code isassociated with the healthcare provider. The unique code may be aone-time use code that expires after a predetermined time if it goesunused. The method 500 includes transmitting 560 an approval message tothe computing device. The approval message may be transmitted as anemail, an SMS text, or some other communication. The approval messagemay include the unique code. The unique code may be displayed on adisplay of the computing device. The unique code may be entered into thesystem via the computing device to authenticate and associate thecomputing device of the healthcare provider with the system.

FIG. 6 is a flow diagram of an example of a method 600 for scheduling anappointment. The method 600 includes obtaining 610 a schedule and feesfrom a healthcare provider. The healthcare provider schedule and feesmay be obtained via an input on a computing device, such as computingdevice 130 shown in FIGS. 1 and 4 . The input may be a touch input, atext input, or a voice input. In an example, the healthcare provider mayindicate their availability to see patients via the input.

The method 600 includes granting 620 access to the schedule and fees.The granting of access may be based on a role assigned to the registereduser of the system. For example, a user with a role “patient” may haveaccess to the schedule and fees. Once access is granted, the patient mayview the schedule and fees on a computing device, such as mobile device120 shown in FIGS. 1 and 4 .

The method 600 includes receiving 630 a request for an appointment, forexample, from the mobile device 120, and transmitting 640 theappointment request, for example, to the mobile device 130. If thehealthcare provider accepts the appointment request, the method 600includes receiving 650 a confirmation from the mobile device 130 andtransmitting 660 the confirmation to the mobile device 120.

FIG. 7 is a flow diagram of an example of a method 700 for electronicprescription (e-prescription). The method 700 includes auto-populating710 patient information to generate an e-prescription. The patientinformation may be obtained from a server, such as server 110 shown inFIG. 1 . The patient information may include the first and last name ofthe patient, patient identification number, preferred pharmacy, or anycombination thereof. The method includes obtaining 720 prescriptioninformation from the healthcare provider. The prescription informationincludes the name of the prescribed medication, dosage, number ofrefills, special instructions, or any combination thereof. The patientinformation and the prescription information may be combined to generatethe e-prescription.

The method 700 includes transmitting 730 the e-prescription to apharmacy or a third party service, for example, the preferred pharmacyindicated in the patient information. The e-prescription may betransmitted via email, SMS text, or any other suitable communication.The method 700 includes transmitting 740 a confirmation and updating thepatient record to include the prescribed medication. The confirmationmay indicate that the e-prescription has been sent to the pharmacy. Theconfirmation may be transmitted to the patient device, the healthcareprovider device, or both. In some embodiments, the method 700 mayinclude receiving 750 a notification from the pharmacy that theprescription is ready for pick up, and transmitting 760 the notificationto the patient device.

FIG. 8 is a diagram of a universal dentition chart 800 in accordancewith embodiments of this disclosure. As shown in FIG. 8 , the universaldentition chart 800 includes a visual representation of a patient'steeth. The visual representation is universal and does not require anumbering system. In an example, the visual representation may be anillustration of the maxillary and mandibular dental arches, as viewedfrom the top down. The teeth may be shown in their approximate properlocation within the dental arch. The physician can identify the teethindividually by the visual representation, and will not require anumbering system for orientation, thereby making this charting systemuniversally recognizable, i.e., by both domestic and foreign dentists,and dentists of different specialties that may have differingnomenclatures for identification of individual teeth. The visualrepresentation can show a tooth that is not present 810, a tooth that ispresent 820, and a tooth that indicates a pathology 830. The toothpathology can be noted 840 and notations can be made. The toothpathology may be linked to particular teeth individually, if desired.

FIG. 9 is a diagram of an example of the mobile telehealth system shownin FIG. 1 . As shown in FIG. 9 , the mobile telehealth system 900includes a server 910, a mobile device 920, a mobile device 930, an EHRsystem 940, and a device 950.

The server 910 may be a computer hardware device or software thatprovides functionality for other programs or devices known as clients.The clients may be mobile devices such as mobile device 920 and mobiledevice 930. In some examples, the EHR system 940 may be a client. Theserver 910 may provide services, such as sharing data or resources amongmultiple clients and devices. The server 910 may perform computationsfor a client.

In this example, the mobile device 920 may be a patient mobile deviceand the mobile device 930 may be a healthcare provider mobile device. Asshown in FIG. 9 , the mobile device 920 is configured to communicatewith device 950. The mobile device 920 may be configured to communicatewith device 950 via a wired or wireless link. For example, the mobiledevice 920 may communicate with device 950 via Bluetooth, WiFi, ZigBee,near-field communications (NFC), ultra-wideband communications (UWC), orany other suitable wireless technology.

The device 950 may be a portable healthcare device, for example,configured for home use by a patient. The device 950 may be part of ahome diagnostic testing kit. The device 950 may include interchangeableparts that perform different functions. For example, an interchangeablepart may include a camera that is configured to scan a body part of apatient, such as a face or other body part. In an example, the scannedbody part may be used to determine an asymmetry that indicates swelling.An interchangeable part may include a camera that is configured to scanan internal portion of a patient body, such as a mouth or ear. Aninterchangeable part may include a light sensor to detect ambient light,for example, when scanning for tooth shade to filter the ambient lightfrom the scan to improve accuracy. In an example, the interchangeablepart may include one or more sensors configured to scan for tooth shade,detect tooth decay, detect gum disease, determine a dental arch, or anycombination thereof. In an example, the one or more sensors may includea spectrophotometer to determine a tooth shade. The spectrophotometermay be configured to perform measurements in a range of approximately400 nm to approximately 700 nm to determine the tooth shade. Determininga dental arch may include generating a two-dimensional orthree-dimensional image from multiple image scans. The two-dimensionalor three-dimensional images may be mapped to data points in a digitalpatient chart, and the digital patient chart may be updated to includethese images. The determined dental arch may be interactive such that itcan be viewed from multiple angles. The one or more sensors may includea camera, an infrared (IR) detector, an ultraviolet (UV) detector, aspectrophotometric detector, a laser detector, a temperature detector,an inertial measurement unit (IMU), or any combination thereof.

The device 950 is configured to obtain data from the one or more sensorsand transmit the data to the mobile device 920. The mobile device 920 isconfigured to determine tooth shade, detect tooth decay, determine gumdisease, determine a dental arch, or any combination thereof, using oneor more artificial intelligence (AI) algorithms. The mobile device 920may be configured to determine whether the device 950 is in the correctposition based on the sensor data. If it is determined that the device950 is not in the correct position, the mobile device 920 may determineinstructions to correct the position, and display or transmit theinstructions. The instructions may include audible and/or hapticfeedback that cause the device 950 to emit an audible alert orvibration. In some examples, the mobile device 920 may transmit the datato the server 910, and the server 910 may be configured to determinetooth shade, detect tooth decay, determine gum disease, determine adental arch, or any combination thereof, using one or more AIalgorithms. In an example, the server 910, the mobile device 920, orboth, may be configured to generate a timeline for display on the mobiledevice 920. The timeline may be generated to so a change in tooth shadeover time, a change in tooth decay over time, a change in gum healthover time, or any combination thereof. In some examples, the server 910,the mobile device 920, or both, may be configured to generate aprediction of a change in tooth shade over time, a change in tooth decayover time, a change in gum health over time, or any combination thereof.The prediction may be based on the effectiveness of a commercial productor prescription product. The prediction may take into account patientmedical data in order to determine the prediction.

The mobile device 920, the mobile device 930, or both, may be configuredto obtain a medical history of the patient. The term “medical history”as used herein may include dental history. In some examples, the medicalhistory may be obtained by transmitting a request to the server 910. Therequest may include an instruction to retrieve the medical history or adigital patient chart from the EHR system 940. In some examples, themedical history may be obtained via an input on the mobile device 920,such as a touch input or a voice input. The mobile device 920 may beconfigured to transmit the medical history to the server 910. In someembodiments, the mobile device 920 may be configured to upload one ormore documents and/or images to the server 910. In some embodiments, theserver may obtain a medical history or a portion of a medical historyfrom the EHR system 940. The EHR system 140 is associated with thehealthcare provider. The EHR system 140 is configured to storeelectronic health records of patients of the healthcare provider. TheEHR system 140 may be configured to generate, store, and update adigital patient chart. The digital patient chart may be generated basedon the medical history. In some examples, the server 910 may beconfigured to generate the digital patient chart and transmit thedigital patient chart to the EHR system 940 for storage. The digitalpatient chart is an electronic file that includes health data associatedwith a given patient. The health data may include text, diagrams,images, audio, video, or any combination thereof. The EHR system 940 maybe configured to transmit the digital patient chart to the server 910,which may transmit the digital patient chart to the mobile device 920,mobile device 930, or both, for display. The EHR system 940 may belocated on premises at the office of the healthcare provider, or it maybe at a remote location away from the healthcare provider office. In anexample, the server 910 may obtain an EHR from the EHR system 940. Theserver 910 may be configured to receive the medical history or portionsof the medical history from the mobile device 920 and the EHR system940, compile the medical history, and transform the compiled medicalhistory into a unified format. The unified format of the medical historymay be stored on the server 910.

FIG. 10 is a flow diagram of an example of a method 1000 for homehealthcare access. At 1010, the method 1000 includes receiving data froma device, for example, device 950 shown in FIG. 9 . The data may includeimage data, temperature data, inertial measurement unit (IMU) data,infrared (IR) data, and ultraviolet (UV) data, spectrophotometric data,or any combination thereof. At 1020, the method 1000 includes displayingand/or storing the data. The data may include image data that isdisplayed on a display, for example, a display of the mobile device 920shown in FIG. 9 . In an example, the data may be stored in a memory ofthe mobile device 920 or transmitted to the server 910 for furtherprocessing or storage. Displaying the data may include verifying aspecific tooth or location in the patient's mouth so that it isassociated with a corresponding tooth or location on a dental record,and displaying when the tooth or location is verified. One or more AIalgorithms may be used to verify the specific tooth or location. The oneor more AI algorithms may be used to automatically map each tooth orlocation using captured images to generate a dental chart. The one ormore AI algorithms may be used to guide the patient to the correct toothor location to enable the patient to perform a self-scan. In an example,the patient may be guided to a particular tooth that was subject to aprevious root canal. The guidance may be provided via audio and/orhaptic feedback. In another example, the patient may provide a voiceinput, such as “What tooth is this?” and receive an audible or textresponse from the mobile device 920 or the device 950 in response to thevoice input.

At 1030, the method 1000 includes determining a tooth shade, a decaystate, a disease state, or any combination thereof. The determining mayinclude processing the obtained data, such as spectrophotometric data,using one or more AI algorithms and/or a neural network, such as aconvolutional neural network (CNN), for example. The determining mayinclude verifying a specific tooth so that it is associated with acorresponding tooth on a dental record. In a tooth shade example, thedetermining may include filtering out an ambient noise signal from theobtained data. At 1040, the method may include obtaining EHR data. TheEHR data may be used to determine a decay state or a disease state.

At 1050, the method 1000 includes determining one or more products. Theone or more products may be determined based on the determined toothshade, decay state, disease state, or any combination thereof. The oneor more products may be determined based on the EHR data. For example,the EHR data may include allergy information of the patient, the methodis configured to eliminate products to which the patient is may beallergic. The one or more products may include tooth straighteningproducts, tooth whitening products, antibiotics, fluoride products,analgesics, or any combination thereof. The tooth whitening products mayinclude dental trays, tooth whitening gels, tooth whitening strips, orthe like. Determining the one or more products may include displaying avisual comparison of the effectiveness of each product based on thepatient data. One or more AI algorithms may be used to determine a levelof tooth color lightening that may be possible based on the patient'sexisting tooth color as determined by the shade detecting device, suchas device 950. The visual comparison can be used by the patient todetermine which product is best for them. For example, the achievabletooth color lightening levels for each product may be displayed on adisplay of the mobile device 920 such that the patient is enabled toselect the product according to their preference.

At 1060, the method 1000 includes determining whether a prescription forthe one or more products is needed. This step may include referencing alook up table (LUT) to determine whether a prescription is needed. If itis determined that a prescription is needed, the method 1000 includestransmitting 1070 a notification to a physician device, such as mobiledevice 930 shown in FIG. 9 . The notification may be transmitted via aserver, such as server 910 shown in FIG. 9 . The notification may bedisplayed on the physician device and enable the physician to approve ordeny the prescription.

If a prescription is not needed, the method 1000 includes displaying1080 a notification to order the one or more products. If it isdetermined that a product is ordered, the EHR may be updated at 1090 toindicate the ordered product. If it is determined that a product isordered, the method 1000 may arrange for purchase and delivery of theproduct.

In some examples, the method may include monitoring the scans atprescribed times and documenting the progress until the patient achievesa desired result.

As used herein, the terminology “computer” or “computing device”includes any unit, or combination of units, capable of performing anymethod, or any portion or portions thereof, disclosed herein.

As used herein, the terminology “processor” indicates one or moreprocessors, such as one or more special purpose processors, one or moredigital signal processors, one or more microprocessors, one or morecontrollers, one or more microcontrollers, one or more applicationprocessors, one or more central processing units (CPU)s, one or moregraphics processing units (GPU)s, one or more digital signal processors(DSP)s, one or more application specific integrated circuits (ASIC)s,one or more application specific standard products, one or more fieldprogrammable gate arrays, any other type or combination of integratedcircuits, one or more state machines, cloud-based computing processors,or any combination thereof.

As used herein, the terminology “memory” indicates any non-transitorycomputer-usable or computer-readable medium or device that can tangiblycontain, store, communicate, or transport any signal or information thatmay be used by or in connection with any processor. For example, amemory may be one or more read only memories (ROM), one or more randomaccess memories (RAM), one or more registers, low power double data rate(LPDDR) memories, one or more cache memories, one or more semiconductormemory devices, one or more magnetic media, one or more optical media,one or more magneto-optical media, or any combination thereof.

As used herein, the terminology “instructions” may include directions orexpressions for performing any method, or any portion or portionsthereof, disclosed herein, and may be realized in hardware, software,cloud-based computing environment(s), or any combination thereof. Forexample, instructions may be implemented as information, such as acomputer program, stored in memory that may be executed by a processorto perform any of the respective methods, algorithms, aspects, orcombinations thereof, as described herein. Instructions, or a portionthereof, may be implemented as a special purpose processor, orcircuitry, that may include specialized hardware for carrying out any ofthe methods, algorithms, aspects, or combinations thereof, as describedherein. In some implementations, portions of the instructions may bedistributed across multiple processors on a single device, on multipledevices, which may communicate directly or across a network such as alocal area network, a wide area network, the Internet, or a combinationthereof.

As used herein, the terminology “determine” and “identify,” or anyvariations thereof, includes selecting, ascertaining, computing, lookingup, receiving, determining, establishing, obtaining, or otherwiseidentifying or determining in any manner whatsoever using one or more ofthe devices and methods shown and described herein.

As used herein, the terminology “example,” “embodiment,”“implementation,” “aspect,” “feature,” or “element” indicates serving asan example, instance, or illustration. Unless expressly indicated, anyexample, embodiment, implementation, aspect, feature, or element isindependent of each other example, embodiment, implementation, aspect,feature, or element and may be used in combination with any otherexample, embodiment, implementation, aspect, feature, or element.

As used herein, the terminology “or” is intended to mean an inclusive“or” rather than an exclusive “or.” That is, unless specified otherwise,or clear from context, “X includes A or B” is intended to indicate anyof the natural inclusive permutations. That is, if X includes A; Xincludes B; or X includes both A and B, then “X includes A or B” issatisfied under any of the foregoing instances. In addition, thearticles “a” and “an” as used in this application and the appendedclaims should generally be construed to mean “one or more” unlessspecified otherwise or clear from the context to be directed to asingular form.

Further, for simplicity of explanation, although the figures anddescriptions herein may include sequences or series of steps or stages,elements of the methods disclosed herein may occur in various orders orconcurrently. Additionally, elements of the methods disclosed herein mayoccur with other elements not explicitly presented and described herein.Furthermore, not all elements of the methods described herein may berequired to implement a method in accordance with this disclosure.Although aspects, features, and elements are described herein inparticular combinations, each aspect, feature, or element may be usedindependently or in various combinations with or without other aspects,features, and elements.

What is claimed is:
 1. A method comprising: receiving spectrophotometricdata and image data from a device; displaying the image data;determining a tooth shade based on the spectrophotometric data;obtaining electronic health record (EHR) data; and determining a productbased on the tooth shade and the EHR data.
 2. The method of claim 1,further comprising: determining whether a prescription is needed basedon the determined product.
 3. The method of claim 2, further comprising:transmitting a notification to a physician device when it is determinedthat a prescription is needed.
 4. The method of claim 2, furthercomprising: displaying a notification to order one or more products whenit is determined that a prescription is not needed.
 5. The method ofclaim 3, further comprising: updating the EHR.
 6. The method of claim 1further comprising: generating a visual comparison of two or moreproducts based on an effectiveness of the two or more products.
 7. Themethod of claim 6, wherein the visual comparison is based on patientdata.
 8. The method of claim 1, wherein the product is a tooth whiteningproduct.
 9. A method comprising: obtaining, via a user interface of afirst mobile device, a patient selection; obtaining, via the userinterface of the first mobile device, an appointment selection;obtaining, via the user interface of the first mobile device, a medicalhistory; obtaining, via the user interface of the first mobile device,payment information; in response to obtaining the payment information,transmitting an invitation to a second mobile device; receiving a firstnotification from the second mobile device; obtaining, via the userinterface of the first mobile device, a check in; in response toobtaining the check in, transmitting a second notification to the secondmobile device; opening a channel between the first mobile device and thesecond mobile device, wherein the channel is a real-time session channelto conduct a telehealth visit.
 10. The method of claim 9, wherein thefirst mobile device is associated with a patient.
 11. The method ofclaim 9, wherein the second mobile device is associated with ahealthcare provider.
 12. The method of claim 9 further comprising:obtaining, via a user interface of the second mobile device, aconfirmation.
 13. The method of claim 12, wherein the first notificationis transmitted in response to obtaining the confirmation.
 14. The methodof claim 12, wherein the confirmation indicates that an appointment isconfirmed.
 15. The method of claim 14 further comprising: displaying, ona display of the first mobile device, the confirmation.
 16. The methodof claim 9 further comprising: obtaining, via a user interface of thesecond mobile device, an indication of visit completion.
 17. The methodof claim 16 further comprising: transmitting a third notification inresponse to obtaining the indication of visit completion.
 18. The methodof claim 17 further comprising: displaying, on a display of the firstmobile device, the third notification.
 19. A method comprising:automatically populating patient information to generate an electronicprescription; obtaining, from a user interface of a first device,prescription information, wherein the prescription information includesa prescribed medication; transmitting the electronic prescription to apharmacy, wherein the electronic prescription includes the patientinformation and the prescription information; and transmitting aconfirmation that indicates that the transmission of electronicprescription to the pharmacy is complete.
 20. The method of claim 19,wherein the confirmation is transmitted to a patient device.